This CHECK was incorrect.

DataPointer::SecureAlloc wraps OPENSSL_secure_zalloc, which by design transparently falls back to a regular CRYPTO_zalloc when the secure heap is not available:

• --secure-heap=0 (the default), secure heap is never initialized, so every SecureAlloc returns a non-secure pointer.
• Windows, secure-heap initialization is gated behind #ifndef _WIN32 in InitCryptoOnce, so it's never initialized there either.
• BoringSSL does not implement OPENSSL_secure_zalloc at all; ncrypto falls back to OPENSSL_malloc + memset and sets secure_=false.
• OpenSSL with secure heap enabled but exhausted, OPENSSL_secure_zalloc silently falls back to the regular heap.

The comment directly above SecureBuffer already documents this: "Without --secure-heap, OpenSSL's secure heap is disabled, in which case this has the same semantics as using OPENSSL_malloc." A non-secure fallback is an expected, documented outcome, so asserting isSecure() is not a valid invariant.

Why it didn't fire before

The CHECK only "passed" due to a bug in ncrypto::DataPointer::SecureAlloc, which unconditionally set secure_=true regardless of whether the returned pointer actually came from the secure heap. That bug is fixed in ncrypto (using CRYPTO_secure_allocated(ptr) to track actual use of secure heap), which in turn exposed the CHECK as unsound on default cli options, on Windows, and made the process crash on BoringSSL builds where secure_ was already correctly false.

Impact

Paired with the ncrypto fix randomUUID() (the only caller of secureBuffer) continues to work exactly as before; it just no longer aborts on BoringSSL / when the ncrypto provenance fix is in place.